The present invention relates to the use of cryptographic techniques by computer applications.
It aims more particularly to offer application security services to various applications, written in a mobile code language (MCL for short) and running on various computer platforms. These application security services may require access to various types of cryptographic resources (CR for short) contained in varied cryptographic media. Thus the aim is to be able to mutualize these CRs between the applications through an architecture that is open and ready for the evolution of the techniques employed, particularly of the platforms, the cryptographic methods (algorithms, key sizes, etc.), the cryptographic media and standards, the application security services, the applications relying on these application security services, etc.
Amongst the applications in MCL covered by the invention, mention can be made for example of the tele-procedure, workflow, email and document publication applications.
By being written in a mobile code language, they can be independent of the platform on which they run. This language may for example be:                Java (see “The Java Language Specification” published by Sun Microsystems, Inc.);        CaML (see http://caml.inria.fr/);        C# (see “C# Language Specification” published by Microsoft Corporation); etc.        
The expression “computer platform” refers to the hardware and software environments suitable for supporting the execution of applications in MCL. The platforms concerned are for example:                computers equipped with the “Windows” operating system from Microsoft Corporation (version 95/98/ME/NT/2000/XP) and an “Internet Explorer” browser from Microsoft Corporation or “Netscape Navigator” from Netscape Communications Corporation;        computers equipped with the MacOS 8/9/X operating system from Apple Computer, Inc. and an “Internet Explorer” or “Netscape Navigator” browser;        “Sun Solaris” platforms from Sun Microsystems, Inc. furnished with a “WebSphere” type server from International Business Machines Corporation; etc.        
The application security services that are being offered to the applications are for example electronic signature, electronic signature verification, encryption, decryption timestamping, timestamp verification, secure protocol and authentication services. They use various types of CR such as cryptographic keys, certificates, algorithms allowing them to be used, etc.
The cryptographic media may be of the smart card type, a module able to be connected to a USB (“Universal Serial Bus”) port called “USB token”, a crypto-hardware card, a PCMCIA (“Personal Computer Memory Card International Association”) card, a software store, etc.
There are numerous cryptographic standards concerning cryptographic algorithms, key generation, the format of messages of a cryptographic nature, secure protocols, etc.
The two most widely used signature algorithms with public key are RSA (“Rivest Shamir Adelman”) and DSA (“Digital Signature Algorithm”). The RSA may also be used for encryption. The RSA is the subject of a standard known as PKCS#1 (Public Key Cryptography Standard No. 1′) published by RSA Security, Inc. The, most used hashing algorithms are SHA-1 and MD5. The best known secret key algorithms are DES (“Digital Encryption Standard”), Triple DES, AES (“Advanced Encryption Standard”), IDEA (“International Data Encryption Algorithm”), RC4, KASUMI and MISTY.
The most widely used formats for signed messages are:                PKCS#7, published by RSA Security, Inc. and by the Internet Engineering Task Force (IETF) as RFC 2315, which has been adopted in CMS (“Cryptographic Message Syntax”, see RFC 2630 of the IETF), these standards being used particularly in the S/MIME (“Secure Multipurpose Internet Mail Extensions”) specification for signed emails;        PGP corresponding to the signed messages originating from the PGP (“Pretty Good Privacy” marketed by Networks Associates Technology, Inc.) software and its equivalents;        XML-DSig, forming part of the family of XML (“extended Markup Language”) data formats.        
The most widely used formats for encrypted messages are PKCS#7/CMS and PGP.
For access to cryptographic resources (CR), there are high level interfaces and low level interfaces. The high level interfaces, in particular PKCS#11 and CAPI, offer a level of abstraction relative to the medium of the cryptographic elements managed.
PKCS#11 is a public standard and free to use, published by RSA Security, Inc. It describes an application programming interface (API) allowing low level cryptographic operations such as the generation and storage of keys, the electronic signature, the encryption and decryption of data, etc. However, PKCS#11 does not mutualize the CRs between the different applications that make use of it. PKCS#11 does not manage the trust certificate chains. It cannot be invoked from mobile code languages. This interface is used particularly in “Netscape Navigator” in order to open the cryptographic functionalities of the navigator and of the messaging client to third party suppliers. This interface is also employed in most products that require this same openness. The majority of cryptographic hardware suppliers offer a PKCS#11 module for accessing their products.
CAPI (“Crypto API”) is an API developed by Microsoft Corporation and available only on the “Windows” platforms. It offers application security functions and functions of signature verification and of management of trust certificate chains absent from PKCS#11. CAPI is not open-ended and cannot be used to add functions such as timestamping or new protocols. CAPI carries out mutualization of the CRs to which it has access between the applications which make use of it. But it cannot generally be invoked from the mobile code languages. A cryptographic module interfacing in CAPI in order to offer security services is called a CSP (“Crypto Service Provider”). To be usable via CAPI, the CSPs must be signed electronically by Microsoft Corporation which for this requires access to the sources of the CSP. The major suppliers of cryptographic hardware usually offer a CSP for accessing their product.
Other interfaces for accessing CRs exist at a lower programming level, that is to say offering less abstraction relative to the CRs managed.
Each hardware cryptographic medium possesses a set of basic instructions to which it can respond. These instructions, sent directly over the connectors of the medium, are used to perform the basic cryptographic operations. Usually these basic instructions are not public, or at least not documented.
The PC/SC (“Personal Computer/Smart Card”) standard aims to offer a very low level of abstraction relative to these instructions, in order that communication between the workstation and the cryptographic medium (for example the smart card) is performed according to a set of instructions common to all the cryptographic media. Most of the CSPs and PKCS#11 modules rely, for their low interface, on PC/SC. Each cryptographic medium usually possesses a PC/SC driver which is invoked in the CSPs or in the PKCS#11 modules via the standard PC/SC interface and which is based on the aforementioned basic instructions. PC/SC provides mutualized access to certain CRs (smart cards, USB tokens) for the applications which are based on it. But it cannot generally be invoked in mobile code languages and it does not provide high level services.
Software cryptographic media, for their part, are usually stores of keys and of certificates contained in files that have a format that may or may not be documented. “Netscape Navigator” keeps the cryptographic keys and certificates in two files called cert7.db and key3.db whose format is stable even on changes of browser version. The known format of this file may be a sufficient interface for a service to be able to access these keys and certificates. An interface for access to these files exists on certain platforms, particularly NSS (“Netscape Security Services”). It involves proprietary formats.
Mobile code languages (MCL) are programming languages whose resultant code is not dependent on one microprocessor or on one operating system. To run, the program needs to find a similar execution environment on the various computers on which it is required to run.
The MCLs that are of primary interest are those that are used also to produce web applications. The most widely used is the Java language from Sun Microsystems, Inc. Java web applications running in a browser environment are called applets. Another MCL that has appeared more recently is the C# language from Microsoft Corporation. The example that will be more particularly considered in the present application is that of Java, but the concepts apply to any other MCL.
MCLs may propose cryptographic interfaces to the applications. In the Java example, the Java cryptographic architecture (JCA, “Java Cryptographic Architecture”) and the Java cryptographic extension (JCE, “Java Cryptographic Extension”) play this role in order to be able to manipulate certificates, keys, algorithms, etc. With Java version 2 the “Trusted API” also appeared which is used to manage trust by means of public key certificates.
An application in MCL may need to access functionalities that are not available in its execution environment. If these functionalities are available in dynamic library form dependent on the platform, the Java environments can be used to access these resources via specified but not unified interfaces:                JNI (“Java Native Interface” from Sun Microsystems, Inc.) applying to recent browsers;        JRI (“Java Runtime Interface” from Netscape Communications Corporation) applying to certain former versions of “Netscape Navigator” or on certain platforms;        RNI (“Raw Native Interface”) from Microsoft Corporation) applying only in the “Internet Explorer” browser.        
The techniques mentioned above form disparate bricks in the composition of secure web applications. Nothing is provided to make them work together.
For accessing CRs from a Java applet, the choices are very limited, even nonexistent. A Java applet cannot use the CRs of the browser in which it is running. Nor can it use CRs accessible via a PKCS#11 interface. As for the JCA/JCE resources, they are often poorly recognized (or not recognized at all) in the browsers. Additionally, these JCA/JCE resources, when they are recognized, cannot be mutualized between several applications. To be mutualizable, a resource must be accessible via a standard interface independent of the programming language and of the platform.
For the use of the cryptographic standards, the standard formats PKCS#7, PGP, and XML-DSig are not recognized in the MCLs.
The interfaces for accessing CRs are usually insufficient to fully provide the security services that are required by the applications that may call upon them.
Thus, PC/SC allows only calls to the functions available on the smart card, which are extremely limited (reading a certificate, having a key signed, usually). PKCS#11 allows the manipulation of more complex objects, but provides no function for verifying trust certificate chains, and does not include complex functions such as timestamping or calls to communication protocols. CAPI allows the verification of trust chains but handles neither the OCSP protocol (“Online Certificate Status Protocol”, RFC 2560, IETF) nor timestamping (see RFC 3161, IETF).
In these conditions, each program requiring the call to these CRs must in itself implement the chaining logic of the elementary security bricks, which considerably increases the cost of development. Furthermore, it generates risks of security failure in the developed application.
In addition, the implementations of the various most widely used interfaces are still not identical from one manufacturer to another, which requires each application to be adapted to each CR supplier. For example, a service that operates with a USB token of supplier A will not be able to operate with that of supplier B if the implementations of the PKCS#11 interface produced by both of them differ.
The CRs are of different natures on the station, accessible via extremely varied interfaces. For reasons of complexity and cost, the applications usually implement only one type of interface, thus closing access to the other CRs.
It also frequently happens that an application itself supports an independent CR via a proprietary interface and that this resource is not accessible to the other applications.
Thus, in the current state of the art, the CRs are not all accessible to a given application and it may be that a CR is not accessible to all the applications.